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I. Real Party in Interest. 

The real party in interest is Microsoft Corporation, the assignee of all right, title 
and interest in and to the subject invention. 



II. Related Appeals and Interferences. 
None. 

III. Status of Claims. 

Claims 1-1 5, 20, 23-25, and 27-29 stand rejected and are pending in the 
Application. 

Claims 1 -1 5, 20, 23-25, and 27-29 are appealed. 
Claims 16-19, 21, 22, and 26 stand cancelled. 

IV. Status of Amendments. 

A Final Office Action was mailed on 8/20/2008. No claim amendments have 
been submitted since the Final Office Action was mailed. 

V. Summary of Claimed Subject Matter. 

The pending independent claims are claims 1 , 10, 12, 20, 23, 28, and 29. 
Claim 1: 

A system for performing client-centric load balancing of multiple globally- 
dispersed servers (Fig. 2, servers 200, 202), the servers being accessed by clients (Fig. 
2, client 208) connecting through an ISP having a domain name server (DNS-ISP) (Fig. 
2, DNS-ISP 206), the servers further having an authoritative domain name server (DNS- 
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A) (Fig. 2, DNS-A 204) associated therewith and an external domain name server (DNS- 

B) (Fig. 2, DNS-B 218), the system comprising: 

one of a plurality of load balancing domain name servers (DNS-LBs) deployed in 
a physical proximity from which the actual network latency of the clients to the 
multiple globally-dispersed servers may be measured (p. 6, lines 3-1 1), the DNS-LBs 
having stored therein IP address information of the multiple globally-dispersed servers 
to be load balanced (p. 1 7, lines 1 7-22; p. 1 8, lines 8-1 1 ; p. 22, lines 9-12), the DNS- 
LBs each sending mapping information to the DNS-B relating the DNS-LB's IP address 
to an IP address of the DNS-ISP (p. 1 8, lines 10-13) to which the DNS-LB is in a 
physical proximity from which the actual network latency of the clients to the globally- 
dispersed servers may be measured (p. 6, lines 5-9), the DNS-LBs determining 
performance characteristics of each of the multiple globally-dispersed servers (p. 20, 
line 1 7, to p. 21 , line 4), a DNS-LB receiving DNS lookup requests sent from its 
respective physically-proximate clients to the DNS-LB's corresponding DNS-ISP (p. 20, 
lines 1-16; p. 21, line 25 to p. 22, line 2), the DNS lookup requests comprising 
respective hostsnames of some of the globally-dispersed servers (p. 19, lines 23-25; 
p. 3, lines 7-14), the DNS-LB using its measurements of actual network latency from 
the clients to the globally-dispersed servers (p. 1 8, lines 1 -5; p.5, lines 19-21; p. 6, 
lines 3-9) to resolve the DNS lookup requests to respective IP addresses of the some of 
the globally-dispersed servers, where DNS lookup request's hostname can be resolved 
to multiple of the IP addresses and the DNS-LB returns to the client the IP address that 
has lower network latency (p. 21 , lines 5-9). 
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Claim 10: 

A method of performing client-centric load balancing of multiple globally- 
dispersed servers (Fig. 2, servers 200, 202), the servers being accessed by clients (Fig. 
2, client 208) connecting through an ISP having a domain name server (DNS-ISP) ) (Fig. 
2, DNS-ISP 206), the servers further having an authoritative domain name server (DNS- 
A) (Fig. 2, DNS-A 204) associated therewith, the method comprising the steps of: 

receiving IP address information from the DNS-A for the servers to be load 
balanced (p. 1 7, lines 1 7-22; p. 1 8, lines 8-1 1 ; p. 22, lines 9-1 2); 

providing the IP address information to a plurality of load balancing domain 
name servers (DNS-LB) (p. 1 7, lines 1 7-22); 

receiving mapping information associating DNS-ISP IP address information to IP 
address information of a DNS-LB (p. 6, lines 1 8-20; p. 1 6, line 1 4, to p. 1 7, line 2) 
located in a physical proximity from which the actual network latency from the clients 
to the globally-dispersed servers is measured by the DNS-LB from a location physically 
proximate to the ISP's point of presence (col. 6, lines 5-9; p. 22, line 22, to p. 23, line 
8; p. 24, lines 3-4); and 

referring DNS address inquiries from a DNS-ISP to a physically proximate DNS- 
LB in accordance with the mapping information (p. 1 6, line 23, to p. 1 7, line 2), a DNS 
address inquiry comprising a hostname corresponding to multiple of the globally- 
dispersed servers (p. 19, lines 23-25; p. 3, lines 7-14), and wherein the DNS-LB 
selects one of the multiple servers according to the DNS-LB's determining of client-to- 
server latency performance and answers the DNS address inquiry by returning the IP 
address of the selected server (p. 18, lines 1-5; p.5, lines 19-21; p. 6, lines 3-9; p. 21, 
lines 5-9) . 
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Claim 1 2: 

A method of performing client-centric load balancing of multiple globally- 
dispersed servers (Fig. 2, servers 200, 202), the servers being accessed by clients (Fig. 
2, client 208) connecting through an ISP having a domain name server (DNS-ISP) (Fig. 
2, DNS-ISP 206), the servers further having an authoritative domain name server (DNS- 
A) associated therewith (Fig. 2, DNS-A 204) , the method comprising the steps of: 

obtaining, by a load balancing domain name server (DNS-LB), IP address 
information for a DNS-ISP (p. 6, lines 3-9; p. 16, lines 8-1 1), the DNS-LB located in a 
physical proximity from which the actual network latency of the clients may be 
measured (p. 1 6, lines 2-1 1 ; p. 6, lines 5-9; p. 1 8, lines 1 3-1 7; p. 1 9, lines 5-7); 

providing a mapping of an IP address of the DNS-LB to the IP address 
information of the DNS-ISP to an external domain name server (p. 6, lines 1 8-20; p. 
16, line 14, to p. 17, line 2); 

receiving IP address information for the servers (p. 17, lines 17-22; p. 18, lines 
8-11; p. 22, lines 9-12); 

monitoring performance of the servers at the received IP addresses by the DNS- 
LB transmitting communications to the IP addresses of the servers (p. 7, lines 13-15; 
p. 20, line 17, to p. 21, line 4); 

receiving at the DNS-LB a DNS name query that was sent from one of the clients 
to the DNS-ISP, the DNS name query querying for an IP address of a hostname that 
corresponds to multiple of the servers (p. 19, lines 20-20; p. 20, lines 11-16); and 

providing at least one IP address for a server in response to the DNS name query 
by selecting the server, based on the monitoring step, from among the multiple servers 
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that correspond to the hostname, and by returning the IP address for the selected 
server (p. 20, lines 1 7-24). 

Claim 20: 

A method of performing client-centric load balancing of multiple globally- 
dispersed content servers for handling content requests from clients (Fig. 2, servers 
200, 202), the servers being accessed by clients (Fig. 2, client 208) connecting through 
an Internet service provider's (ISP's) point of presence (POP), the ISP having a domain 
name server (DNS-ISP) (Fig. 2, DNS-ISP 206), the servers further having an 
authoritative domain name server (DNS-A) (Fig. 2, DNS-A 204) associated therewith 
containing information regarding the IP addresses of the servers (p. 17, lines 17-22; p. 
1 8, lines 8-1 1 ; p. 22, lines 9-1 2), the method comprising the steps of: 

deploying a plurality of load balancing domain name servers (DNS-LBs) in a 
physical proximity from which the actual network latency of the clients connecting to 
the ISP POPs may be measured (col. 6, lines 5-9; p. 22, line 22, to p. 23, line 8; p. 24, 
lines 3-4); 

communicating IP address information for a plurality of second level domain 
name servers (DNS-Bs) to the DNS-As to enable the DNS-As to refer name queries to 
the DNS-Bs (p. 16, line 23, to p. 18, line 7); 

providing, by the DNS-LBs to the DNS-B, mapping information associating IP 
addresses of the DNS-LBs to IP addresses of their corresponding DNS-ISPs to enable 
the DNS-B to refer name queries from DNS-ISPs to DNS-LBs (p. 6, lines 1 8-20; p. 16, 
line 14, to p. 1 7, line 2) ; and 

communicating IP address information of the servers to the DNS-LBs (p. 1 7, 
lines 1 7-22; p. 1 8, lines 8-1 1 ; p. 22, lines 9-1 2); 
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monitoring, by the DNS-LBs, performance of the servers (p. 7, lines 13-15; p. 
20, line 17, to p. 21, line 4); 

receiving at a DNS-LB a DNS name query that was sent from one of the clients to 
the DNS-ISP, the DNS name query querying for an IP address of a hostname that 
corresponds to multiple of the servers (p. 1 9, lines 20-20; p. 20, lines 1 1 -1 6), the DNS 
name query having been sent from the client in response to the client starting a service 
request needing an IP address for the hostname (p. 24, lines 1 -2); and 

providing, by the DNS-LB, in response to the DNS name query from the DNS-ISP, 
the IP address of a server by selecting the IP address from among the IP addresses of 
the multiple of the servers based on the step of monitoring (p. 1 8, lines 1 -5; p.5, lines 
19-21; p. 6, lines 3-9; p. 20, lines 1 7-24; p. 21 , lines 5-9). 

Claim 23: 

A method for load balancing content servers, each of the content servers being 
associated with a same domain name (p. 3, lines 7-11; p. 19, lines 20-25), the method 
comprising: 

receiving a DNS request to resolve the domain name from an ISP DNS server (p. 
16, line 23, to p. 17, line 2); 

identifying at least one load balancing server from a group of load balancing 
servers, the identified load balancing server measuring network latency from the load 
balancing servers to the content servers (p. 1 8, lines 1 -4; p. 20, lines 1 7-24; p. 6, 
lines 3-8; p. 21, lines 12-16; p. 20, lines 17-24); and 

sending the IP address of the identified load balancing server to the ISP DNS 
server (p. 1 6, line 23, to p. 1 7, line 2), the identified load balancing server configured 
to select, based on its measuring of network latency, at least one of the content 
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servers and to resolve the domain name with an IP address associated with the 
selected content server (p. 1 8, lines 1 -5; p.5, lines 19-21; p. 6, lines 3-9; p. 21 , lines 
5-9). 

Claim 28: 

A method comprising: 

receiving at a load-balancing domain name service server (DNS-LB) a DNS 
lookup request received by and redirected from a domain name service server of an 
internet service provider (DNS-ISP) (p. 16, line 23, to p. 17, line 2), the request having 
been sent by a client of the DNS-ISP (p. 20, lines 1-16; p. 21, line 25 to p. 22, line 2), 
the request containing a hostname corresponding to a plurality of IP addresses of 
servers serving content (p. 21, lines 5-9; p. 19, lines 23-25; p. 3, lines 7-14), where 
the request was forwarded by the DNS-ISP when the DNS-ISP: determined that an IP 
address for the hostname was not cached at the DNS-ISP (p. 1 9, line 22, to p. 20, line ) 
and obtained the IP address of the DNS-LB by issuing a DNS query for the hostname (p. 
20, lines 1-16; p. 20, line 23, to p. 21, line 2); 

measuring network latency from the DNS-LB to the servers that correspond to 
the hostname in the request by repeatedly sending communications from the DNS-LB 
to the servers (p. 1 8, lines 1 -4; p. 20, lines 1 7-24); 

in response to receiving the redirected DNS lookup request of the client at the 
DNS-LB (p. 20, lines 11-16), selecting an IP address of one of the servers that 
correspond to the hostname, where the IP address is selected from among the servers 
based on the measuring of network latency to the servers (p. 1 8, lines 1 -5; p.5, lines 
19-21; p. 6, lines 3-9; p. 21 , lines 5-9); and 

returning to the client the selected IP address (p. 21 , line 1). 
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Claim 29: 

A method performed by a DNS server that provides DNS service for a plurality of 
clients, the method comprising: 

receiving from a client a DNS lookup request requesting an IP address for a 
server having a hostname specified by the request (p. 1 9, lines 20-20; p. 20, lines 1 1 - 
16); 

in response to receiving the client DNS lookup request, determining that an IP 
address for the requested hostname is unavailable on the DNS server (p. 1 9, line 22, to 
p. 20, line ) and in response issuing a DNS query for the hostname (p. 20, lines 1-16; 
p. 20, line 23, to p. 21, line 2); 

in response to issuing the DNS query for the hostname by the DNS server, 
receiving a referral to an authoritative DNS server (DNS-A) that corresponds to the 
hostname (p. 1 5, lines 14-17; p. 20, lines 1-3), the referral providing an IP address of 
a domain name service load-balancing server (DNS-LB) and causing the DNS server to 
query the DNS-LB for an IP address of the hostname in the client request (p. 20, lines 
1-16); 

in response to querying the DNS-LB, receiving an IP address from the DNS-LB 
(p. 1 7, lines 20-24), where the IP address corresponding to the hostname was selected 
by the DNS-LB based on network measurements obtained by repeated transmissions 
from the DNS-LB to IP addresses that correspond to the hostname (p. 18, lines 1-4; p. 
20, lines 17-24); and 

sending the IP address received from the DNS-LB to the client that sent the 
lookup request for the web server having the hostname specified by the request (p. 21 , 
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line 1). 



VI. Grounds of Rejection to be Reviewed on Appeal. 

1 . The rejection of claims 1-11 under 35 U.S.C. § 1 03 as obvious over U.S. 
Patent No. 6,671 ,259 to He in view of Cisco Distibuted Director, by Delgadillo. 

Item 6 of the Final Office Action lists claims 1-15, 20, 23-25, and 27-29 as 
being obvious over He in view of Delgadillo. However, Delgadillo is referred to only in 
items 6a- 6k of the Final Action, which reject claims 1-11. 

2. The rejection of claims 12-1 5, 20, 23-25 and 27-29 under 35 U.S.C. § 
1 03 as obvious over He in view of U.S. Patent application No. 2005/0022203 to 
Zisapel. 
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1 VII. Argument. 

2 A. Summary of teachings of He, Delgadillo, and Zisapel. 

3 1. He 

4 1 -a. He does not measure latency. 

5 The rejection suggests that He's LB server measure latency. However, the 

6 system in He only measures network load and server load. 

7 He summarizes the nature of its measurement at col. 4, lines 1 2-20 (emphasis 

8 added): 

9 In the present invention, the network measurements 

10 includes the measurement of load or network traffic 

1 1 experienced by a server. Load refers to the total amount of 

1 2 client requests which the server is servicing or the total 

1 3 amount of operations being performed by a server. Network 

1 4 traffic is the total amount of data packets (traffic on the 

1 5 network) being carried to each of the servers from the client 

1 6 systems, as well as, from each of the servers to the client 

1 7 systems. 
18 

1 9 Rather than measuring latency, He measures data volume and counts client 

20 requests. 

21 

22 1 -p. — He's load balancing ( LB) servers only acquire load measures or measure 

23 received packets, thev do not themselves transmit/communicate to content/web 

24 servers for the purpose of measuring latency. 

25 The rejection posits that He's load balancing servers themselves measure 

26 network latency. See the Final Action, p. 5, lines 8-1 2; p. 1 0, lines 1 0-1 4; etc., citing 

27 col. 4, lines 5-24, and col. 6, lines 30-67 of He. 

28 Preliminarily, the rejection equates the load measures of He with network 
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latency. Applicant disagrees, but for discussion only will treat them as equivalent. 

He's LB servers either (1) obtain load/latency information from another source, 
or (2) they measure the volume of pass-through network traffic. 

Regarding point (1), He describes the LB server as obtaining the network 
measurements (col. 4, line 10, 21 , and 34) which are providedto the LB server 
("network measurements are performed on each of the servers or gathered from each 
server using network measurement devices", col. 4, lines 9-1 1 , note "server" and "LB 
server" are two distinct terms; "LB server 67 examines ... the network measurements 
provided for the servers 69 and 71", col. 5, lines 62-63; "LB server examines ... the 
network measurements provided for the servers", col. 1 2, lines 22-23; "network 
measurements provided for the servers", col. 1 1 , line 67; "network measurements 
received '[not performed] by the load balancing server", col. 16, lines 36 and 52). 

Regarding point (2), where He describes the LB server itself performing 
measurement, it is only measurement of the actual traffic that is passing through the 
LB server (col. 8, lines 45-67). The LB server alternates between a macro-control 
balancing mode and a micro-control balancing mode. In micro-control mode, "the 
server monitors the information flow on a packet per packet basis and determines the 
appropriate server to service each packet", col. 7, lines 55-57. In macro-control 
mode, the "the LB server examines the amount of client requests the LB server is 
receiving" (col. 1 3, lines 48-49). To the extent that the LB server actually measures, it 
is passive measurement, not measurement to a server for the purpose of measuring 
latency or the like. 

In sum, He's LB server only acquires measurements by either obtaining network 
load measurements from another source, measuring the number of client requests, or 
measuring pass-through traffic volume. Thus, in no case does He's LB server actually 
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1 communicate to a server (e.g., Web/content server) for the purpose of measuring 

2 latency thereto. 
3 

4 1 -c. He's servers are located near servers being balanced, not clients. 

5 The rejection acknowledges this aspect of He (Final Action, p. 6, lines 1 3-1 4; p. 

6 8, lines 7-1 1 ; p. 10, lines 1 -3; etc.). 
7 

8 1 -d. Improbable to modify He by placing LB servers near clients and away 

9 from proximity to servers. 

10 As discussed above, He's LB servers measure traffic packet-by-packet and 



1 1 switch servers on a packet-by-packet basis. He's LB server "monitors the information 

1 2 flow on a packet per packet basis ... the LB server can dynamically change from one 

1 3 server to another quickly and during the same session or connection between the 

14 client system and the server" (col. 7, lines 55-60). In macro-control mode, "the LB 

1 5 server ... constantly monitors] the information flow on a packet per packet basis and 

16 determines the appropriate server to service each packet " (col. 8, lines 10-13). This 

1 7 type of fine-grained control of server traffic would be impossible to perform if the LB 

1 8 server were placed in proximity to clients (e.g., far across the network) and removed 

19 from the proximity of the servers that it is balancing. It would also be unlikely that an 

20 LB server could measure packet-by-packet network packets to a group of servers 



21 without proximity thereto. 
22 

23 2. Delgadillo 

24 2 -a. Del gadillo measures latency from Agents located near servers to clients. 

25 Delgadillo teaches two basic approaches for selecting a server to resolve a DNS 
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1 lookup request; the use of ICP and BGP routing table metrics (hop distances), and the 

2 use of link latency metrics (page 2, right column, items 1 . and 2.)- The teachings 

3 related to hop distances (ICP/BCP info.) are not relevant to the instant case, which 

4 deals with latency. In other words, while the Examiner is correct that Delgadillo tries to 

5 resolve to a "close" server, only the latency (round-trip, or "RTT") teachings of 

6 Delgadillo are relevant for balancing, because the present claims recite using latency 

7 not topological proximities. 

8 Among the five specific measurement techniques mentioned at pages 4-6 of 

9 Delgadillo (DRP-External, DRP-lnternal, DRP-Server, DRP-MED, and DRP-RTT), only the 

1 0 DRP-RTT ("round trip times") teachings relate to latency. DRP-External, DPR-lnternal, 

1 1 DRP-Server, and DRP-MED are not based on network latency but rather are based on 

1 2 topological measures such as autonomous system (AS) hop counts, which are 

1 3 significantly different than latency measures, as noted by Delgadillo at page 3, second 

14 paragraph. In sum, hop counts (ICP and BGP information) do not reveal latency, which 

1 5 is why Delgadillo teaches a separate technique to measure latency. 

1 6 Regarding Delgadillo's measurement of latency, Delgadillo describes this 

1 7 approach at page 6, right column ("DRP-RTT"). Specifically, Delgadillo states 

18 (emphasis added): 

1 9 [DRP-RTT] enables the DistributedDirector to include 

20 server-to-client (since most data travels from server-to- 

21 client) round trip times (RTTs) in traffic redirection 

22 decisions. This configuration metric enables the network 

23 administrator to optimize server load distribution based on 

24 server-to-client link latency , resulting in maximized end- 

25 to-end server access performance. When the DRP-RTT 

26 metric is configured, the DistributedDirector issues a DRP- 

27 RTT query to each DRP Server Aaent . Upon receipt of these 

28 queries, each DRP Server Aaent determines the round trip 

29 time (link latency) between itself and the requesting client. 
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1 The Director can then identify the "best" server as that 

2 associated with the DRP Server Agent returning the lowest 

3 round trip time within a specified tolerance level. 
4 

5 In Delgadillo, an Agent, per instruction from the DistributedDirector, finds 

6 network latency by determining the latency "between itself [the Agent] and the 

7 requesting client". Furthermore, in the first paragraph of page 3, Delgadillo mentions 

8 "DRP Agents are also used to determine the round-trip times (link latencies) between 

9 the distributed servers and clients." In Delgadillo, latency is measured by a DRP Agent, 

1 0 and the measure is necessarily from the DRP Agent and to the client. Were the client 

1 1 performing the measurement, the DistributedDirector would not need to tell the Agent 

12 to perform the measurement. 

13 This is consistent with Delgadillo's figures. Figure 1 b (page 2) shows "DRP 

14 Client-to-Server Round-Trip Time Metrics" are gathered and used. Note that the DRP 

1 5 Agents ("DRP") are located near the "Servers", not near the "Client". Note also that "RTT 

16 Measurement" dashed lines are between Agents and clients. According to Figure 1 b, 

1 7 The DistributedDirector, via its DRP Agents, "[m]easures client-to-DRP server round- 

1 8 trip times" ("DRP Agents are also used to determine the round-trip times (link 

19 latencies) between the distributed servers and clients", page 3, first para.). It is a DRP 

20 Agent, near a Server, that measures latency to a client, not to a Server. Thus the 

21 latency measure is a measure from the Agent and to the client. Each figure in 

22 Delgadillo shows the DRP Agents located near Servers, and no client is depicted as 

23 having a local DPR Agent. 

24 While Delgadillo does use the terminology "client-to-server" in some places, it 

25 uses the term "server-to-client" where describing how latency is measured ("server 

26 load distribution based on server-to-client link latency", page 6, column 2). This 
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1 ambiguous terminology is resolved by Delgadillo's description of how latency is 

2 actually measured, which, as shown above, is from a DRP Agent to a client. Note that 

3 Delgadillo at several places refers to its Agents as "DRP Server Agents" (page 6, column 

4 2). Clearly, an Agent located with a group of Servers and supports the system by 

5 measuring in the direction from Servers/Agent to the Client. 



6 For further understanding, see Step 4 at page 1 1 of Delgadillo: 

7 the DistributedDirector issues DRP queries to each DRP 

8 server agent configured for the subdomain. After the DRP 

9 server agents receive the DRP requests, they [Agents! gather 
!0 the requested DRP metrics. As previously discussed, there 

1 1 are several DRP metrics including an "external metric" an 

1 2 "internal metric" a "server metric" and an " RTT metric ." ... 

1 3 the DRP metrics returned provide distances between the 

14 DRP server agents/distributed servers and the client's local 

15 DNS. 
16 



1 7 In sum, there are two notable aspects of Delgadillo's DRP- RTT latency 

18 measurement. First, the measurement direction is from servers and toward clients. 

1 9 Second, the measurement endpoint is the client, not the server (Delgadillo's agents 

20 don't measure latency to servers). 
21 

22 2-b. Delgadillo' s Agents are located near Servers, not near clients. 

23 As shown above, Delgadillo's Agents measure from Agents and to clients. If 

24 Delgadillo's Agents were near the clients, any network latency measurement from 

25 Agent to client would obviously be trivial and meaningless for server selection. 

26 Furthermore, as mentioned above, Delgadillo's figures show DPR Agents near Servers, 

27 and Delgadillo refers to Agents as "server agents", noting that "DRP server agents are 

28 typically peers to border routers (BCP speakers) that support the distributed end 
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1 servers for which DistributedDirector service distribution is desired." By design, DRP 

2 server agents are near "end servers". Furthermore, "DRP server agents must have 

3 access to full BCP and ICP routing tables" (p. 3, left column, lines 1 -3). Generally, for 

4 security, access to sensitive routing information such as BCP and IGP routing tables is 

5 kept local. Note that the Agents of Delgadillo actually run on the operating system of a 

6 router supporting the servers (p. 3, left column, 3d para., and footnote 1), which both 

7 minimizes security issues and further shows the improbability of placing agents near 

8 clients as opposed to near the servers being balanced. 

9 Moreover, the routers/Agents in Delgadillo are by design located near Web 

10 Servers, because the DistributedDirector product is for WWW server providers \o 

11 address scalability issues ("maintaining high 5e/ve/"availability, server performance ... 

1 2 are key challenges faced by today's WWW sites. The DistributedDirector seeks to solve 

13 these scalability issues", Abstract, 3d para.). The DistributedDirector product is 

14 intended and configured for Web service providers, not clients. 

1 5 Finally, Delgadillo teaches a "Server Availability" technique at a section titled 

16 "Server Availability Parameter Redirects Clients to Available Servers" (page 8, left 

1 7 column). Here, Delgadillo mentions that server availability is tested when the 

1 8 " DistributedDirector attempts to create a TCP connection to each of the distributed 

19 servers" (emphasis added). There would be no reason for the DistributedDirector 

20 server to check server availability if the DRP Agents were already measuring to the 

21 servers. Because DRP Agents use TCP probes (see page 6, right column, middle), if the 

22 Agents were sending the TCP probes to the servers, they would already know whether 

23 the servers were available, and the DistributedDirector would have no need to itself 

24 check availability. For this reason also, it is clear that DRP Agents do not measure 

25 latency to the Web servers of Delgadillo. 
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1 

2 3. Zisapel 

3 3-a. Zisapel's load balancers (LBs. e.g.. LB1 and LB2) are near servers being 

4 balanced, not clients. 

5 Zisapel discusses load balancers (LBs) using latency (see, e.g., paras. [001 7] and 

6 [0026]). Zisapel describes its LBs, at para. [0033] (emphasis added): 

7 Server farms 1 0 and 1 2 typically comprise a load balancer 16 

8 and 1 8 respectively, which may be a dedicated load balancer 

9 or a server or router configured to operate as a load 

1 0 balancer, with each of the load balancers being connected 

1 1 to one or more servers 20. Load balancers 1 6 and 1 8 are 

12 alternatively referred to herein as LB1 and LB2 respectively. 



13 

1 4 According to the plain language of Zisapel, an LB is part of a server farm and is 

1 5 even connected to the servers. Furthermore, the Figures of Zisapel clearly show each 

1 6 server farm as having a directly connected local LB. No figure of Zisapel shows an LB 

1 7 put in proximity to clients. Nor would Zisapel have an LB near clients and away from 

1 8 servers, because, as shown next, the LBs transmit to a client to measure latency to the 

1 9 client. 
20 

21 3-b. Zis apel's LBs measure latency to the client, not to the server. 

22 Zisapel's LBs use polling to measure latency (para. [001 7]). Paragraph [001 8] 

23 clearly states that polling is performed by an LB pinging or sending a TCP ACK to the 

24 client. Paragraph [0040] states that "[t]o determine comparative network proximity, 

25 LBI, LB2, and LB3 preferably each send a polling request 58 to client 26 using known 

26 polling mechanisms" (emphasis added). Figure 2C of Zisapel unequivocally shows LB 

27 servers transmitting "POLLING REQUEST'S originating at the LBs and following lines 
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1 with arrows pointing to and ending at the client. Figure 2D shows the LBs receiving 

2 "POLLING RESPONSES from the client, not from a server. 

3 For brevity, the preceding sub-sections of section A. will be referred to without 

4 reference to section A (i.e.,, " 3-b " refers to VII.A.3-b). 

5 

6 B. The rejection of claims 1 and 1 0 as obvious over He in view of Delgadillo. 

7 1. Claim 1. 

8 Claim 1 recites "one of a plurality of load balancing domain name servers (DNS- 

9 LBs) deployed in a physical proximity from which the actual network latency of the 

10 clients to the multiple globally-dispersed servers may be measured". Claim 1 also 

1 1 recites "the DNS-LB using its measurements of actual network latency from the clients 

1 2 to the globally-dispersed servers to resolve the DNS lookup requests". 

13 Notably, claim 1 recites measurements of network latency from clients to the 

14 servers. In other words, the measure has two aspects. First, there is a direction; from 

1 5 DNS-LBs that are physically proximate to clients, to the servers. Second, there is a 

1 6 measurement endpoint; the globally-dispersed servers (note that the DNS-LB of claim 

17 1 is provided with the addresses of the servers). 

18 Regarding the direction of measurement, as shown above in section 2-a . 

19 Delgadillo does not measure latency in a direction from client to server, but rather 

20 measures latency from an Agent (located near a server) to a client. The direction of 

21 latency measurement is not a distinction without a difference. Latency from A to B in 

22 an IP network, for example, can differ from the latency of B to A. It has been well 

23 known since the inception IP routing that routing can be asymmetric. See "An 

24 Experimental Study of Asymmetric Routing" (Karir and Zhang, 1 997-1 998, available at 

25 terpconnect.umd.edu/~karir/papers/wosbis98.pdf). Although published after the date 
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1 of the present invention, the following references also discuss the asymmetric nature 

2 of IP routing, a protocol not significantly changed since the time of the present 

3 invention: "On Routing Asymmetry in the Internet" (2005, 

4 www.cs.ucr.edu/~krish/yhe_gcom05.pdf), "What is asymmetric routing?" (date 

5 unknown, my.stonesoft.com /support/document.do?docid=l 377), among others. 

6 Furthermore, aside from the numerous references that describe the asymmetric 

7 (direction-sensitive) nature of IP routing, Applicant has previously made note of this 

8 phenomena. See the Amendment filed 5/28/2008, page 1 1 , last paragraph ("It is well 

9 known in the field of IP routing that routing is not symmetric. That is, the route from 

1 0 node A to node B can be much different than the route from node B to node A. The 

1 1 latency from a client to a server might involve a local or nearby bottleneck which the 

1 2 server communicating to the client might not experience"). Applicant's prior 

1 3 discussion of the potential significance of the direction of latency measure has not 

14 been traversed by the Examiner. 

1 5 The rejection is in error because Delgadillo measures latency from the direction 

16 of servers toward clients (from Agents near servers, to routers near clients). In a 

1 7 similar vein, as also shown in section 2 -a . Delgadillo does not measure latency to the 

18 server. 

19 Regarding the target of latency measurement, claim 1 clearly recites a DNS-LB 

20 measuring latency to the servers. As shown in section 2-a . Delgadillo measures to 

21 clients, not servers. As shown in section 1-b . He's LB servers do not measure latency 

22 from themselves to servers. In fact, as shown in section 1-a . He doesn't even measure 

23 latency (see Final Action, p. 5, lines 8-1 2, which appears to cite He as teaching latency 

24 measurement). 

25 Claim 1 recites that DNS-LBs are "deployed in a physical proximity from which 
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1 the actual network latency of the clients to the ... servers may be measured, ... a DNS- 

2 LB receiving DNS lookup requests sent from its [the DNS-LB's] respective physically- 

3 proximate clients". That is, the DNS-LB is in physical proximity to the client such that 

4 actual latencies from client to the servers can be measured. He's servers are not near 

5 clients (see section hzc above). The rejection is in error because, as shown in section 

6 1 -d, He cannot be modified to move LB servers away from servers and in proximity to 

7 clients without defeating its main purpose. As shown in section 2-b . Delgadillo's 

8 Agents (which the rejection compares to DNS-LBs) are near servers, not clients. 
9 

10 2. Claim 10 . 

11 •• Claim 10 recites a " client-centric load balancing method. More 

1 2 particularly, claim 1 0 recites "clients connecting through an ISP", and "network latency 

1 3 from the clients to the globally-dispersed servers is measured by the DNS-LB from a 

14 location physically proximate to the ISP's point of presence". 

1 5 The rejection, page 8, lines 8-12, notes that He does not teach this feature. The 

16 rejection refers to Delgadillo, stating 'The DRP server agents are typically peers to 

1 7 border routers that support the distributed end server for which distribution is desired 

18 (See page 2, col. 2)" (Final Office Action, page 8, lines 14-16). 

19 First, Delgadillo has no mention of an "ISP's point of presence". Delgadillo 

20 doesn't even mention or suggest a client ISP, nor does He. An ISP point of presence 

21 (PoP) is a well-known term of art. A search of "ISP point of presence" on any major 

22 Internet search engine reveals numerous definitions and well accepted use of the term 

23 in the art of computer networking. For example, and without limitation, an ISP PoP can 

24 be a physical location where an ISP has equipment (Cisco ISP Essentials, Greene and 

25 Smith, 2002, p. 223). 
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1 Second, as shown above in section Z^a, Delgadillo does not measure "network 

2 latency from the clients to the globally-dispersed server? . In contrast, it measures 

3 latency from Agents to clients. 

4 Third, as shown in section 2-b . Delgadillo's Agents measure from the proximity 

5 of servers, which is not "from a location physically proximate to the [client] ISP's point 

6 of presence". Moreover, the Examiner's own statement indicates that the agents in 

7 Delgadillo "support the distributed end server" , which is the opposite of supporting a 

8 client or a client ISP's point of presence. 

9 Fourth, Claim 1 0 recites both "clients connecting through an ISP", and "network 

10 latency from the clients to the globally-dispersed servers is measured by the DNS-LB 

1 1 from a location physically proximate to the ISP's point of presence". That is, latency is 

1 2 measured from a location physically proximate to a PoP of the ISP that clients connect 

13 through. The latency is from the direction of the client's ISP to the server. As shown 

1 4 above in section 2-b . Delgadillo measures latency from the direction of the server 

1 5 toward the client. 

16 Fifth, claim 1 0 recites "client-to-server latency performance". The rejection 

1 7 cites only He (p. 8, lines 5-7). As shown in section He does not measure latency, 

1 8 it measures traffic volume and the number of client requests. 
19 

20 C. Rejection of claims 1 2, 20, 23, 28, and 29 as obvious over He in view of Zisapel. 

21 

22 1 . Claim 12 . 

23 Claim 1 2 recites "clients connecting through an ISP", and "the DNS-LB located in 

24 a physical proximity from which the actual network latency of the clients may be 

25 measured". The rejection notes that He does not teach this feature, and cites Zisapel 
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1 (p. 9, line 1 7, to p. 1 0, line 3). However, as shown in section 3-a, Zisapel's LBs are 

2 near servers being balanced, not clients. And, as shown in section 3^b, Zisapel's LBs 

3 measure latency to the client, not to the server (note claim 1 2 also recites "monitoring 

4 performance of the servers at the received IP addresses by the DNS-LB transmitting 

5 communications to the IP addresses of the servers", and "selecting the server, based on 

6 the monitoring step"). 

7 The rejection states that He teaches the monitoring by the DNS-LB (LB server) 

8 transmitting communications to the IP addresses of the servers. However, as shown in 

9 section He does not measure network latency, and as shown in section 1-b . He's 

10 LB server either obtains load data from another source, or it measures pass-through 

1 1 packets and client requests. 
12 

13 2. Claim 20. 

14 Claim 20 recites a method of "client-centric load balancing", including 

1 5 "deploying a plurality of load balancing domain name servers (DNS-LBs) in a physical 

16 proximity from which the actual network latency of the clients connecting to the ISP 

1 7 POPs may be measured", and "monitoring, by the DNS-LBs, performance of the 

18 servers". As shown in sections V^b, l^c, and 3za, He's and Zisapel's load balancers are 

19 in proximity to measure server latency. Furthermore, as shown in section 1 -d . He's LB 

20 servers cannot be modified to be away from servers and in proximity from which client 

21 latency can be measured. 
22 

23 3. Claim 23. 

24 Claim 23 recites "the identified load balancing server measuring network latency 

25 from the load balancing servers to the content servers", and "select[ing a server], based 



serial no.: 09/714,406 
docket: 150789.01 

23 



1 on its [i.e., load balancing server] measuring of network latency". As shown in section 

2 Lza, He does not measure network latency. As shown in section 1-c . He's LB servers 

3 are located near the servers and therefore it would not make sense to use a latency 

4 measure from the LB servers to the content servers (client connectivity would not be 

5 taken into account). Similarly, as shown in section 3-a . Zisapel's LBs are near (even 

6 connected to) the servers being balanced, not clients; LB-to-server latency would be 

7 trivial and would be independent of the client. As shown in section 3-b . Zisapel's LBs 

8 measure latency to the client, not to the server, as recited in claim 23. Furthermore, as 

9 shown in section i^d, He must have its LB server near the servers being balanced; He 

10 cannot be modified to have its LB servers in a position to allow for a meaningful 

1 1 measure of latency to a server. 
12 

13 4. Claim 28. 

1 4 Claim 28 recites "measuring network latency from the DNS-LB to the servers 

1 5 that correspond to the hostname in the request by repeatedly sending communications 

1 6 from the DNS-LB to the servers", and "selecting an IP address of one of the servers ... 

1 7 based on the measuring of network latency to the servers". The rejection notes that He 

1 8 does not teach this feature, and refers to Zisapel ("He et al fails to teach where the IP 

1 9 address was selected by the DNS-LB based on transmissions form [sic] the DNS-LB to 

20 the IP address that measure network latency from the DNS-LB to the IP address of the 

21 server", Final Action, p. 1 5, lines 8-1 3). 

22 However, as shown above in section 3za, Zisapel's LBs are located near server 

23 farms and are connected to the servers, therefore measurement of latency to servers 

24 would not allow a server to be chosen based on client information. Furthermore, 

25 Zisapel's servers measure latency from the LB to the clients (as shown in section 3-b) . 
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1 which is in contrast to claim 28's measurement of latency by sending communications 

2 from the load balancer (DNS-LB) to the servers being balanced. As shown earlier, 

3 latency measures (via transmission or communication between A and B) can be 

4 sensitive to the direction of measurement. 

5 In sum, no reference of record teaches a load balancing DNS server (DNS-LB) 

6 measuring network latency from itself (the DNS-LB) to the servers being balanced. All 

7 of the references disclose load balancers residing and operating at the server end. 
8 

9 5. Claim 29. 

10 Claim 29 recites "a method performed by a DNS server that provides DNS service 

11 for a plurality of clients", where a hostname is resolved to an IP address. In particular, 

1 2 "the IP address corresponding to the hostname was selected by the DNS-LB based on 

1 3 network measurements obtained by repeated transmissions from the DNS-LB to IP 

14 addresses that correspond to the hostname". In other words, the DNS-LB makes 

1 5 network measurements by transmitting from itself to the IP addresses. 

16 The rejection cites paragraphs [0036] to [0038] of Zisapel. However, as shown 

1 7 above, Zisapel positions LB servers with server clusters, and the LB servers measure 

1 8 latency from the LB servers to the clients, not to the servers. 

19 He's LB servers use network measurements, but the measurements are not 

20 performed by the LB servers, and they are not measurements obtained by transmitting 

21 from the LB server to the server IP addresses. He selects a server based on "network 

22 measurements" (col. 1 , line 9; col. 4, lines 8, 22-23, 27, 33, and 37; col. 5, line 63; col. 

23 8, lines 37 and 47; etc.). According to He, col. 4, lines 1 3-20: 

24 the network measurements includes the measurement of 

25 load or network traffic experienced by a server. Load refers 

26 to the total amount of client requests which the servpr is 
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1 servicing or the total amount of operations being performed 

2 by a server. Network traffic is the total amount of data 

3 packets (traffic on the network) being carried to each of the 

4 servers from the client systems, as well as, from each of the 

5 servers to the client systems. 
6 

7 He's network measurements clearly refers only to the volume of traffic. This 



8 type of information is incapable of being measured by an LB server simply transmitting 

9 to the server (e.g., pinging, ending an HTTP request, etc.). This is why He describes 

1 0 the LB server as obtaining the network measurements (col. 4, line 1 0, 2 1 , and 34) 

1 1 which are provided 'to the LB server ("LB server 67 examines ... the network 

12 measurements provided for the servers 69 and 71", col. 5, lines 62-63; "LB server 

1 3 examines ... the network measurements provided for the servers", col. 1 2, lines 22-23; 

14 "network measurements provided for the servers", col. 1 1 , line 67; "network 

15 measurements received [not performed] by the load balancing server", col. 16, lines 36 

16 and 52). 

1 7 Where He actually describes the LB server performing a type of measurement, it 

1 8 is only measurement of the actual traffic that is passing through the LB server (col. 8, 

19 lines 45-67). The LB server alternates between a macro-control mode and a micro- 

20 control mode. In micro-control mode, "the server monitors the information flow on a 

21 packet per packet basis and determines the appropriate server to service each packet", 

22 col. 7, lines 55-57. In macro-control mode, the "the LB server examines the amount of 

23 client requests the LB server is receiving" (col. 1 3, lines 48-49). The only 

24 measurements performed by the LB server are the amount of client requests and 

25 information flow (volume) passing through. 

26 In sum, He teaches LB servers near servers being balanced. The LB servers 

27 receive measurements of volume of network traffic as well as server load. The LB 
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1 servers select IP addresses based on this information. The only measurement 

2 performed by the LB server itself is monitoring the number of connections it is 

3 handling. None of the measurement data mentioned in He is measurement performed 

4 by the LB server transmitting from the LB server to the servers being balanced. 

5 He cannot be modified to place LB servers away from servers and near or in 

6 physical proximity to clients (or DNS of clients' ISP). He's LB servers switch between a 

7 micro control mode and a macro control mode: 

8 "If the LB server is dynamically configured in micro 

9 controlled mode, then the LB server provides the IP number 

1 0 of the LB server to represent a path from the client system 

11 to a server with the LB server acting as the gatekeeper in 

12 step 40" (col. 7, lines 37-40); 
13 

14 "Micro-control mode places the LB server in greater control 

1 5 of the flow of information from the client systems to the 

1 6 servers . If the LB server is dynamically configured to be in 

1 7 micro-control mode, the [LB1 server monitors the 

18 information flow on a packet 55 per packet basis and 

19 determines the appropriate server to service each packet " 

20 (col. 7, lines 51-58). 
21 



22 Because LB servers of He monitor the packets of content servers, it is necessary 

23 for them to be near the servers. The He LB servers would not operate as intended if 

24 they were modified to be proximate to clients rather than servers. Furthermore, they 

25 would not be able to control the flow of information. In sum, the LB servers cooperate 

26 closely with the content servers, receiving load measurements, handling client traffic 

27 for the server, acting as a conduit to dynamically changing servers, etc. (see col. 2, line 

28 23; and col. 6 lines 7-10). 
29 
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VIII- Claims Appendix. 



1 . (Previously Presented) A system for performing client-centric load balancing 
of multiple globally-dispersed servers, the servers being accessed by clients 
connecting through an ISP having a domain name server (DNS-ISP), the servers further 
having an authoritative domain name server (DNS-A) associated therewith and an 
external domain name server (DNS-B), the system comprising: 

one of a plurality of load balancing domain name servers (DNS-LBs) 
deployed in a physical proximity from which the actual network latency of the clients to 
the multiple globally-dispersed servers may be measured, the DNS-LBs having stored 
therein IP address information of the multiple globally-dispersed servers to be load 
balanced, the DNS-LBs each sending mapping information to the DNS-B relating the 
DNS-LB's IP address to an IP address of the DNS-ISP to which the DNS-LB is in a 
physical proximity from which the actual network latency of the clients to the globally- 
dispersed servers may be measured, the DNS-LBs determining performance 
characteristics of each of the multiple globally-dispersed servers, a DNS-LB receiving 
DNS lookup requests sent from its respective physically-proximate clients to the DNS- 
LB's corresponding DNS-ISP, the DNS lookup requests comprising respective 
hostsnames of some of the globally-dispersed servers, the DNS-LB using its 
measurements of actual network latency from the clients to the globally-dispersed 
servers to resolve the DNS lookup requests to respective IP addresses of the some of 
the globally-dispersed servers, where DNS lookup request's hostname can be resolved 
to multiple of the IP addresses and the DNS-LB returns to the client the IP address that 
has lower network latency. 
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2. (Original) The system of claim 1 , wherein the DNS-B stores the mapping 
information for the plurality of DNS-LBs to forward IP address queries to one of the 
DNS-LBs closest to the DNS-ISP from which the IP address query originated, and 
wherein the DNS-LB closest to the DNS-ISP returns the IP address to the DNS-ISP of the 
server having the best performance characteristics. 

3. (Original) The system of claim 1 , wherein the DNS-B stores the mapping 
information for the plurality of DNS-LBs to forward IP address queries to one of the 
DNS-LBs closest to the DNS-ISP from which the IP address query originated, and 
wherein the DNS-LB closest to the DNS-ISP returns the IP address of the DNS-LB to the 
DNS-ISP. 

4. (Original) The system of claim 1 , wherein the DNS-B provides its IP address 
information to the DNS-A to enable the DNS-A to forward IP address queries to the 
DNS-B. 

5. (Original) The system of claim 4, wherein the DNS-B receives IP address 
information from the DNS-A for the servers to be load balanced. 

6. (Original) The system of claim 1 , wherein the DNS-LB is a client of the DNS- 
ISP. 

7. (Original) The system of claim 1 , further comprising a DNS-B deployed on 
each Internet backbone, and wherein each DNS-B contains the mapping information 
for all of the DNS-LBs stored therein. 
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8. (Original) The system of claim 1 , wherein the DNS-LB transmits updated 
mapping information upon a change of an IP address of the DNS-ISP. 



9. (Original) The system of claim 1 , wherein each of the DNS-LBs transmit 
performance information of the servers to the DNS-B, and wherein the DNS-B utilizes 
the mapping information to determine the proper DNS-LB performance information to 
utilize to select the IP address of the server having the best performance 
characteristics to return to the DNS-ISP from which an IP address query originated. 

1 0. (Previously Presented) A method of performing client-centric load balancing 
of multiple globally-dispersed servers, the servers being accessed by clients 
connecting through an ISP having a domain name server (DNS-ISP), the servers further 
having an authoritative domain name server (DNS-A) associated therewith, the method 
comprising the steps of: 

receiving IP address information from the DNS-A for the servers to be load 
balanced; 

providing the IP address information to a plurality of load balancing domain 
name servers (DNS-LB); 

receiving mapping information associating DNS-ISP IP address information to IP 
address information of a DNS-LB located in a physical proximity from which the actual 
network latency from the clients to the globally-dispersed servers is measured by the 
DNS-LB from a location physically proximate to the ISP's point of presence; and 

referring DNS address inquiries from a DNS-ISP to a physically proximate DNS- 
LB in accordance with the mapping information, a DNS address inquiry comprising a 
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hostname corresponding to multiple of the globally-dispersed servers, and wherein 
the DNS-LB selects one of the multiple servers according to the DNS-LB's determining 
of client-to-server latency performance and answers the DNS address inquiry by 
returning the IP address of the selected server. 

1 1 . (Original) A computer-readable medium having computer executable- 
instructions for performing the steps of claim 10. 

1 2. (Previously Presented) A method of performing client-centric load balancing 
of multiple globally-dispersed servers, the servers being accessed by clients 
connecting through an ISP having a domain name server (DNS-ISP), the servers further 
having an authoritative domain name server (DNS-A) associated therewith, the method 
comprising the steps of: 

obtaining, by a load balancing domain name server (DNS-LB), IP address 
information for a DNS-ISP, the DNS-LB located in a physical proximity from which the 
actual network latency of the clients may be measured; 

providing a mapping of an IP address of the DNS-LB to the IP address 
information of the DNS-ISP to an external domain name server; 

receiving IP address information for the servers; 

monitoring performance of the servers at the received IP addresses by the DNS- 
LB transmitting communications to the IP addresses of the servers; 

receiving at the DNS-LB a DNS name query that was sent from one of the clients 
to the DNS-ISP, the DNS name query querying for an IP address of a hostname that 
corresponds to multiple of the servers; and 

providing at least one IP address for a server in response to the DNS name query 
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by selecting the server, based on the monitoring step, from among the multiple servers 
that correspond to the hostname, and by returning the IP address for the selected 
server. 

1 3. (Original) The method of claim 1 2, further comprising the steps of: 
detecting a change in the DNS-ISP IP address; and 

updating the mapping of the IP address of the DNS-LB to the IP address 
information of the DNS-ISP to the external domain name server. 

1 4. (Original) The method of claim 1 2, further comprising the steps of 
receiving selection criteria for the selection of an IP address; 
receiving a name query from the DNS-ISP; and 

wherein the step of providing at least one IP address for a server in response to 
a name query selected based on the monitoring step further comprises the step of 
providing at least one IP address for a server in response to a name query selected 
based on the monitoring step and on the selection criteria. 

1 5. (Original) A computer-readable medium having computer-executable 
instructions for performing the steps of claim 1 2. 

16-19. (Canceled). 

20. (Previously Presented) A method of performing client-centric load balancing 
of multiple globally-dispersed content servers for handling content requests from 
clients, the servers being accessed by clients connecting through an Internet service 
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provider's (ISP's) point of presence (POP), the ISP having a domain name server (DNS- 
ISP), the servers further having an authoritative domain name server (DNS-A) 
associated therewith containing information regarding the IP addresses of the servers, 
the method comprising the steps of: 

deploying a plurality of load balancing domain name servers (DNS-LBs) in a 
physical proximity from which the actual network latency of the clients connecting to 
the ISP POPs may be measured; 

communicating IP address information for a plurality of second level domain 
name servers (DNS-Bs) to the DNS-As to enable the DNS-As to refer name queries to 
the DNS-Bs; 

providing, by the DNS-LBs to the DNS-B, mapping information associating IP 
addresses of the DNS-LBs to IP addresses of their corresponding DNS-ISPs to enable 
the DNS-B to refer name queries from DNS-ISPs to DNS-LBs; and 

communicating IP address information of the servers to the DNS-LBs; 

monitoring, by the DNS-LBs, performance of the servers; 

receiving at a DNS-LB a DNS name query that was sent from one of the clients to 
the DNS-ISP, the DNS name query querying for an IP address of a hostname that 
corresponds to multiple of the servers, the DNS name query having been sent from the 
client in response to the client starting a service request needing an IP address for the 
hostname; and 

providing, by the DNS-LB, in response to the DNS name query from the DNS-ISP, 
the IP address of a server by selecting the IP address from among the IP addresses of 
the multiple of the servers based on the step of monitoring. 

21. (Cancelled) 
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22. (Cancelled) 



23. (Previously Presented) A method for load balancing content servers, each of 
the content servers being associated with a same domain name, the method 
comprising: 

receiving a DNS request to resolve the domain name from an ISP DNS server; 

identifying at least one load balancing server from a group of load balancing 
servers, the identified load balancing server measuring network latency from the load 
balancing servers to the content servers; and 

sending the IP address of the identified load balancing server to the ISP DNS 
server, the identified load balancing server configured to select, based on its 
measuring of network latency, at least one of the content servers and to resolve the 
domain name with an IP address associated with the selected content server. 

24. (Previously Presented) The method as recited in claim 23, wherein the 
certain characteristics include load level, availability, network latency, or network cost. 

25. (Previously Presented) The method as recited in claim 23, wherein the 
identified load balancing server is situated closest to the ISP DNS server among the 
group of load balancing servers. 

26. (Cancelled) 

27. (Previously Presented) The system as recited in claim 26, wherein the 
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certain characteristics include load level, availability, network latency, or network cost. 

28. (Previously Presented) A method comprising: 

receiving at a load-balancing domain name service server (DNS-LB) a DNS 
lookup request received by and redirected from a domain 1 name service server of an 
internet service provider (DNS-ISP); the request having been sent by a client of the 
DNS-ISP, the request containing a hostname corresponding to a plurality of IP 
addresses of servers serving content, where the request was forwarded by the DNS-ISP 
when the DNS-ISP: determined that an IP address for the hostname was not cached at 
the DNS-ISP and obtained the IP address of the DNS-LB by issuing a DNS query for the 
hostname; 

measuring network latency from the DNS-LB to the servers that correspond to 
the hostname in the request by repeatedly sending communications from the DNS-LB 
to the servers; 

in response to receiving the redirected DNS lookup request of the client at the 
DNS-LB, selecting an IP address of one of the servers that correspond to the hostname, 
where the IP address is selected from among the servers based on the measuring of - 
network latency to the servers; and 

returning to the client the selected IP address. 

29. (Previously Presented) A method performed by a DNS server that provides DNS 
service for a plurality of clients, the method comprising: 

receiving from a client a DNS lookup request requesting an IP address for a 
server having a hostname specified by the request; 

in response to receiving the client DNS lookup request, determining that an IP 
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address for the requested hostname is unavailable on the DNS server and in response 
issuing a DNS query for the hostname; 

in response to issuing the DNS query for the hostname by the DNS server, 
receiving a referral to an authoritative DNS server (DNS-A) that corresponds to the 
hostname, the referral providing an IP address of a domain name service load- 
balancing server (DNS-LB) and causing the DNS server to query the DNS-LB for an IP 
address of the hostname in the client request; , 

in response to querying the DNS-LB, receiving an IP address from the DNS-LB, 
where the IP address corresponding to the hostname was selected by the DNS-LB 

based on network measurements obtained by repeated transmissions from the DNS-LB 

■>* 

to IP addresses that correspond to the hostname; and 

sending the IP address received from the DNS-LB to the client that sent the 
lookup request for the web server having the hostname specified by the request. 
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IX. EVIDENCE APPENDIX. 
None. 
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X. RELATED PROCEEDINGS APPENDIX. 
None. 
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